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A data commumcaUon system referred to as an Asynchronous/Synchronous Converter (110) is provided to facilitate the 
communications between a data terminal equipment (DTE) (100) device using the asynchronous communication port, and a dial-up router 
located in a digital network. When running a dial-up TCP/IP program over the asynchronous port. DTEs (100) use a protocol called 
rZ™l°™?* Point-to-Point Protocol (Asynchronous PPP). On the other hand, dial-up routers usually support Synchronous PPP. Hie data 
communication system of the invention connects the DTE (100) to the digital network and ultimately to the dial-up routers and provides 
two-way conversion between Asynchronous PPP and Synchronous PPP that is transparent to both the DTE (100) and the router This 
two-way conversion is enabled in part by the converter intercepting and storing certain link control protocol (LCP) packets and using data 
in those packets to effect a translation. 6 
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METHOD AND APPARA TUS FOR ASYNCHRONOUS ppp 
AND SYN CHRONOUS PPP CONVERSION 

BACKGROUND OF THE INVENTION 
This invention relates to transmission of information between 
two or more digital devices. More particularly, this invention relates to a 
method and apparatus capable of two-way data transmission and translation 
between a device communicating according to an Asychronous Point-to-Point 
Protocol (Asynchronous PPP) and a device communicating according to a 
Synchronous Point-to-Point Protocol (Synchronous PPP). 

For many decades, digital computer users have interacted with 
centralized computing resource from remote locations. Long before the 
advent of the personal computer (PC), remote users communicated with large 
central mainframe computers by using a remote dumb terminal connected to a 
modem communicating over standard public telephone lines. A modem is a 
device that accepts binary encoded data (generally represented as a square 
wave with two voltage levels, -12 and +12 volts) and translates that data 
xnto signals that can be easily transmitted over the public phone network. 
Generally, the modem translates the binary values into two or more audible 
frequencies by modulating an audible carrier frequency signal. This 
modulated carrier is then transmitted over the phone lines, and a modem on 
the other end of the line demodulates the carrier signal to recover the 
binary data and transmits that data to the central computer. Thus the name 
"modem," which is a contracted combination of "modulate" and "demodulate." 
in the art, generalized names have been used to refer to the modem and dumb 
terminal, with the modem or other equipment the provides communication 
services referred to as a DCE (for Data Communicating Equipment, formerly 
Data Circuit-terminating Equipment) and the dumb terminal or other equipment 
that receives the digital data (such as a PC or digital phone) referred to 
as a DTE (for Data Terminal Equipment). 

As computing has evolved from large mainframes connected to dumb 
terminals to large networks of PCs in an office sharing resources and data 
via a local area network (IAN), the modem has remained. Modems today 
typically connect a home or remote office PC to a central LAN. However, 
modem communication has increasingly not kept up with the need for modern PC 
users to receive complex digital, digitized audio, and digitized video at 
home with the same level of service and speed that they are used to 
receiving when working in an office directly connected to the office LAN. 
The fastest commercially available modems today can transfer data at a rate 
of about 28.8 Kilo bits per second (Kbps). While this is a vast improvement 
over the data rates of 300 bps common just 15 years ago, it is still 
substantially slower than the 1 to 10 to 100 Mega bps (Mbps) possible for 
communications in an interoffice LAN. 
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One limitation to the speed with which remote users can 
communicate with a central computer or LAN is use of standard public phone 
lines. Because of the electrical and transmission line characteristics of 
the public phone network, binary data cannot be directly transmitted as 
simply two voltage levels. The data must first be modulated onto an audible 
carrier signal. This limitation is being increasingly removed as public 
phone companies are providing a new separate service to home and business 
users called ISDN (for Integrated Services Digital Network). ISDN lines may 
look like and enter the home as an ordinary telephone line, but in fact 
connect to a separate ISDN service. This service allows for direct 
transmission of digital data throughout the ISDN network without the need 
for modulation onto an audible frequency. Standard ISDN lines are now 
available to many home users, both in the United States and in other parts 
of the world. In the U.S., ISDN lines are available to home users starting 
at about $30 per month. The least expensive ISDN service can transmit data 
at a rate of 64 Kbps- 

However, commercially available PC'b on the market today cannot 
communicate directly with an ISDN line. Therefore, a DCE device is required 
for communicating data to and from the PC (or other DTE) and then 
transmitting and receiving data over the ISDN according to the ISDN's 
protocol. A number of such DCE devices have become recently commercially 
available. While these devices do not modulate a carrier frequency as do 
standard analog modems, these new ISDN DCE devices are often referred to as 
-ISDN modems- or -digital modems." In order to avoid confusion, the type of 
DCE device provided by the present invention is referred to herein as a 
"converter- because in addition to providing an ISDN connection to a PC, it 
converts between two different types of data transmission, namely 
asynchronous and synchronous transmissions, as described below. A full 
understanding of the present invention requires some knowledge of packet- 
based data transmission as well as synchronous versus asynchronous data 
transmission and these topics are discussed below. 



Point-to-Point Packet Protocols For Remote Users 

Before the advent of the PC, communications between remote DTEs 
and central computers operated on generally a character-by-character 
transmission. Since the remote terminals were dumb, i.e. generally 
incapable of independently performing any computing tasks for the user, 
there had to be communication between the DTE and the central computer each 
time the user wished any computing action to be taken, and as a result, dumb 
terminals typically transmitted characters of data to the central computer 
as each character was typed by the user. PCs have dramatically changed this 
paradigm. When using a PC, most computing operations and application 
programs execute locally on the PC, with the remote computing resource 
contacted only intermittently, perhaps just to load or receive files or 
other data to or from the PC. 
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In order to facilitate intermittent communications between PC's 
and a central computing resource (such as a file server) within a LAN, a 
number of packet-based communications protocols have been adopted. One set 
of such protocols in referred to as TCP/IP (for Transmission Control 
Protocol /Internet Protocol). The TCP/IP protocols are defined in a series 
of documents released by the Internet Engineering Task Force. The documents 
are referred to as RFC's (for Request For Comment). These documents are 
available over the Internet at URL 

http: //www. cis. ohio-state. edu: 80 /hypertext /information/rfc . html or via FTP 
at ds.internic.net. The protocols specify a number of conventions for use 
in packet communications, such as how data in the packets is organized, the 
packet headers, packet addressing, etc. Using these protocols, a PC sends 
and receives data from a centralized computing resource in packets, only 
when needed, and generally in response to a specific request from the user. 

Within the network itself, packet communications under TCP/IP 
are generally multipoint communications, that is, multiple receivers are 
connected to a network line and a transmitter sends out packets on the 
network and any number of receivers or all receivers listen to the packet, 
but only those receivers to whom the address in the packet header indicates 
are addressed to actually examine the data in the packet. The packet must 
contain the address of the sender and the intended receiver. 

An additional set of protocols has been developed for sending 
and receiving TCP/IP packets at a remote PC over a phone line. These 
protocols are referred to as PPP (for Point-to-Point Protocols, the 
predecessors to these PPP protocols where referred to as SLIP for Serial 
Line Internet Protocol). The PPP protocols are described in RFC1661, 
RFC1662 and RFC1663, available from the IETF. The name PPP refers to the 
fact that this protocol is distinct from multipoint protocols in part 
because it is not necessary for every packet transmitted over the PPP 
connection to contain a source or an initial destination address. This is 
true because the PPP connection is between just two devices; any packet 
transmitted by one device must necessarily be received by the other device. 

The protocols just discussed all fit into a layered networking 
standard. In a layered standard, various necessary networking tasks are 
broken down and organized into a number of layers, based on the level of 
abstraction at which the data is being considered by those tasks. Different 
protocols may operate at different layers. For example, the lowest layer is 
generally referred to as the "physical layer" and defines the physical means 
by which data signals are transmitted. The physical layer may incorporate 
one of various protocols for transmission via wires, optical fiber, radio 
waves, or the telephone system. As part of the layered standard, protocols 
operating at one layer must communicate with a variety of different possible 
protocols at the next lower and next higher layer. The layers are somewhat 
independent in that regardless of which physical layer protocol is used, at 
the next highest layer, often called the "data link layer," the same 
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packetizing and addressing protocol may be used. The PPP documents referred 
to above discuss data transmissions at three layers: the physical layer, the 
data link layer, and the network layer and specify protocols that primarily 
operate at the data link layer. 

5 

Asynchronous and Synchronous Communications at the Physical Layer 

At the physical layer, an important characteristic in the 
transmission of data over a wire is whether the communications are bit- 
synchronous or bit— asynchronous. Standard modems transmit data 
10 asynchronously. In asynchronous transmission, bits of data are transmitted 
in very short groups, generally 8-bit bytes. Each byte of data is preceded 
by an additional START BIT and is followed by at least one STOP BIT. The 
term asynchronous is used because there is no shared clock between the 
transmitter and the receiver. One limitation to the speed with which 
15 standard modems may transmit data is the use of asynchronous communications. 
Each 8-bits of data transmitted require at least 2 additional non-data bits 
to be transmitted. Fig. 1 illustrates an example of transmission of 2 bytes 
of data 10a (01111110), and 10b (11100000) using an Asynchronous 
transmission. Each byte of data is preceded by a start bit 12a and followed 
20 by a stop bit 12b. 

ISDN lines and ISDN modems transmit data synchronously. In 
synchronous transmission, bits of data are transmitted continuously in long 
groups. There are no START BITS or STOP BITS and once data transmission 
commences, as far as the physical layer is concerned, it can continue 
25 indefinitely- The term synchronous is used because there is a shared clock 
between the transmitter and the receiver. The shared clock is generally 
carried by and recovered from the data stream itself. This is possible 
because each bit in a synchronous data stream is encoded as a voltage 
transition from either high to low (a "O" bit) or from low to high (a "1" 
30 bit). There is therefore a guaranteed transition during every clock cycle, 
and from these transitions, a clock at the receiver can be continuously 
synchronized with the data stream using a known circuit such as a phase lock 
loop. Contrast this with asynchronous transmissions, where single voltage 
levels are used to encode logical 0*s and I's. In asynchronous 
35 transmission, during transmission of a byte consisting of eight I'b such ae 
11111111 there will be no voltage transitions and therefore no way for a 
receiver to recover a clock from the data stream. Fig. 2 illustrates an 
example of transmission of 3 bytes of data 10a, 10b, and 10c using a 
synchronous transmission protocol. Byte 10c is only partially illustrated. 
40 Asynchronous communication has proven to be the most widely 

adopted method of communication thus far over the public telephone lines 
using a modem. This is partly due to the different amounts of delay and 
distortion that may be experienced in an audible signal through a public 
telephone network. An asynchronous transmission is less sensitive to this 
45 distortion than a synchronous transmission. Essentially all PCs sold today 
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include an asynchronous communications port as standard equipment. This 
port is generally controlled by a standard IC known as a UART (Universal 
Asynchronous Receiver/Transmitter). A number of network software products 
include software drivers for transmitting data over the asynchronous port, 
5 in order for a PC equipped with an asynchronous port to communicate with a 
synchronous transmitter such as an ISDN line, the PC must be provided with 
an apparatus for translating between asynchronous bit streams and 
synchronous bit streams. According to applicant's invention, a PC is 
provided with such an apparatus which translates bits at the physical layer 
10 between asynchronous and synchronous as well as providing higher-layer 
translation as discussed below. 

Asynchronous Byte Stuffing and Synchronous Bit Stuffing 

Among the higher-layer issues that a converter such as 
15 applicant's invention roust handle is translating the manner in which control 
codes are transmitted in asynchronous and synchronous communications. 
Control codes are codes used by transmitter to signal certain conditions to 
the receiver. These conditions might include the start of transmission of a 
block of data, the end of transmission of a block of data, a signal that the 
transmitter is ready to send, a signal that one of the data devices is ready 
to receive, etc. According to the most commonly used protocol asynchronous 
communication can have up to 32 different control codes; codes that are very 
commonly used are XON (0001O0O1) and XOFF (00010011), which stand for 
transmission-on and transmission-of f . In both asynchronous and synchronous 
25 communication, an immediate problem arises with the use of control codes. 
Control codes are essentially a particular string of bits defined to be a 
control code. However, users transmitting data generally must have 
available to them the ability to transmit any of the 256 possible different 
bytes of data, including bytes that are identical to the control codes. The 
protocol, therefore, must provide a method for distinguishing in a data 
stream when a particular bit patten is simple part of the data versus when 
it is a control code. In asynchronous communications, that method is 
referred to as "byte stuffing;" in synchronous communication, that method 
is referred to as "bit stuffing." 
35 According to the most common asynchronous communication 

protocols, "byte stuffing" occurs as follows. A particular asynchronous 
protocol can define any of the first 32 possible 8-bit bytes (00000000 
through 00011111) to be control codes. No bytes need be defined as control 
codes, but if at least one byte is defined as a control code, than an 
additional byte, known as the escape character (ESC) , must also be defined 
as a control code. Those bytes that are control codes may be determined at 
the outset by the protocol or may be negotiated between the receiver and 
transmitter before data transmission begins. After the control codes are 
determined, an asynchronous transmitter may use the control codes to 
45 establish a communication session. Once data transmission begins, the 
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asynchronous transmitter monitors each byte of the data stream before it is 
transmitted and compares that data byte to the defined control codes- When 
the transmitter detects a data byte that is identical to a control code, the 
transmitter inserts or "stuffs" an additional byte, the ESC character, just 
5 before the data byte. In the art, this action is known as "escaping- the 
data byte. When the receiver receives this ESC character, it is then aware 
that the next byte will be a data byte, even though it has the same value as 
a control code. The receiver discards the first received ESC, and receives 
the next byte as a data character. The ESC character is also defined as a 
10 control character; therefore, if the ESC character appears in the data 

stream, it too is "escaped" and the data is transmitted as ESC ESC. This 
method is known as a "byte stuffing" procedure because the ESC byte is 
stuffed into the data stream before each data byte that is identical to a 
defined control character. One ESC byte must be transmitted along with the 
15 data stream for every data byte that happens to be identical to a control 
code, thereby slowing down the overall data transmission rate. 

According to the most common synchronous communication 
protocols, "bit stuffing" occurs as follows. Host synchronous protocols 
define only one control code, known as the flag byte. This code generally 
20 haB the value 01111110. The flag byte both begins and terminates all 
transmissions, as whenever the flag byte is received during data 
transmission, the receiver assumes that the transmission has ended. It is 
therefore necessary that actual data stream sent to the receiver never 
includes an unintentional flag byte. This is accomplished using a bit 
25 stuffing procedure as follows. Whenever the transmitter detects a string of 
five 1 bits in a row in a data stream to be transmitted, the transmitter 
inserts a single 0 into the transmitted data stream just after the string of 
five l's. This 0 is inserted whether the bit following the five l's is a 0 
or a 1. In this way, the transmitter guarantees that any string of six l's 
30 seen by the receiver will be part of a flag byte. The 0 is inserted after 
every five l's regardless of the value of the sixth bit to make it possible 
to restore the original data at the receiver. When the receiver receives 
the data stream, it detects all strings of five l's, at that point the 
receiver examines the sixth bit. If the bit is a 0, it is discarded by the 
35 receiver and the receiver continues to receive data bits; if the sixth bit 
is a 1, then the received knows that it has received a valid flag byte. 

Asynchronous PPP and Synchronous PPP 

A final issue that a converter such as applicants' invention 

40 must handle is capturing and translating data packets that are sent at still 
higher layers of the network standard. The previously discussed PPP 
protocols that are described in RFC1661, RFC1662 and RFC1663 in fact define 
two separate but related protocols, one for Asynchronous PPP and another for 
Synchronous PPP. These protocols differ, among other things, in their 

45 exchange of Link Control Protocol (LAP) packets, which are data packets that 
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are used at the link control layer to format certain transmission parameters 
of the link. in Asynchronous PPP, LCPs are is used to negotiate and 
configure the Asynchronous Control Character Map (ACCM). The ACCM is a 32 
bit flag field that defines which of the 32 possible control characters 
should be escaped accordingly to the encoding rules defined in RFC1662. A 
"1" in a particular location in the ACCM flag field indicates that the 
corresponding control code must be escaped. A -0" in a particular location 
in the ACCM flag field indicates that the corresponding control code need 
not be escaped. ACCM can be negotiated using the parameter negotiation 
protocols defined in RFC1661 and RFC1662 . The default ACCM for Asynchronous 
PPP is FFFFFFFF hex indicating that all control characters (ASCII 0-1F hex) 
are escaped; the default ACCM for Synchronous PPP is 0 indicating that no 
control characters are escaped. While the Synchronous PPP protocol allows a 
transmitter to specify an ACCM, in fact at present no Synchronous devices 
known to the inventors actually use an ACCM or escape any control 
characters. A converter from Asynchronous PPP to Synchronous PPP muBt 
provide an effective means for translating between the two protocols at the 
data link layer. 

From the above it may be seen that what is needed is an 
Asynchronous to Synchronous Converter that provides transparent and two-way 
translation between an Asynchronous PPP connection and a Synchronous PPP 
connection at both the physical and higher layers of the network standard- 

SUMMARY OF THE INVENTION 
The present invention is an Asynchronous PPP to Synchronous PPP 
Converter (which includes an ISDN modem) that allows standard computers 
having an asynchronous port and asynchronous PPP driver software to 
transparently communicate with a synchronous connection such as that 
provided by an ISDN line. The present invention communicates with the DTE 
30 using Asynchronous PPP and with a remote router over an ISDN connection 
using Synchronous PPP. when it receives an Asynchronous PPP packet, a 
converter according to the invention removes the byte- insert ion based 
Asynchronous PPP packet formatting and then encapsulates the data into a 
bit-insertion based Synchronous PPP packet. When the invention receives a 
35 Synchronous PPP packet, it removes the synchronous PPP formatting and 
encapsulates the data into in an Asynchronous PPP packet - 

The present invention accomplishes this transparent translation 
by capturing and storing all ACCM's sent by the Asynchronous PPP or the 
Synchronous PPP connection and removing the ACCMs from the data stream 
40 before transmitting the packets. The invention uses the stored ACCM's to 

properly strip or add escape characters as needed for the protocol specified 
by each device. The present invention accomplishes these tasks through a 
unique combination of software controlled methods and hardware components. 
Though the invention is described in light of a particular hardware 
45 implementation, the methods of the invention may also be practiced on other 
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hardware configurations or solely in software. 

BRIEF DESCRIPTION OF THE DRAWINGS 
FIG. 1 is a timing diagram of an asynchronous transmission? 
5 FIG. 2 is a timing diagram of a synchronous transmission; 

FIG. 3 is a block diagram of a home PC using a converter to 
communicate with a synchronous router on an office LAN according to the 
invention? 

FIG. 4 is a block diagram of an asynchronous /synchronous 
10 converter according to the invention? 

FIG. 5 is a diagram showing the capture translation of ACCM's 
between a DTE, a DCE and a network according to the invention; 

FIG. 6 is a flowchart of the transmission of a packet from an 
asynchronous PPP to a synchronous PPP? 
15 FIG. 7 is a flowchart of the transmission of a packet from a 

synchronous PPP to an asynchronous PPP. 

DETAILED DESCRIPTION OF SPECIFIC EMBODIMENTS 
Fig. 3 is a block diagram of a data communication connection 
20 using a converter according to an embodiment of the present invention- Fig. 
3 shows DTE 100 in communication with a centralized computer network 125 
through an Asynchronous /Synchronous converter HO according to the 
invention. In a particular embodiment, DTE 100 might be a home PC that a 
telecommuting user uses at home to interface with her office LAN 125- Using 
25 an Asynchronous /Synchronous PPP converter 110 according to the invention to 
establish an ISDN connection to the office LAN, the home user can achieve 
data transmission speeds at home that are significantly faster than could be 
achieved with conventional modems. DTE 100 could also be any other type of 
digital device, such as a digital phone or digital video device. 
30 DTE 100 includes a two-way asynchronous port 104, which is 

controlled by UART 105. An asynchronous port such as 104 is provided as 
standard equipment on most PCs sold today. UART 105 is a standard 
commercially available computer circuit designed to accept data from a DTE 
processor or memory and convert that data into a format suitable for 
35 asynchronous transmissions. UART 105 may be programmed to handle lower 

layer asynchronous transmission protocol. It may be a separate chip, such 
as the 16550, or it may be circuitry included onto a larger controller chip. 
DTE 100 also includes Asynchronous PPP driver software 101. This software 
handles higher layer Asynchronous PPP functions, such as organizing data 
40 into Asynchronous PPP packets as well as responding to LCP packets and 

configuring an ACCM. According to the invention, Asynchronous PPP driver 
software 101 may be standard network software for connection to an 
Asynchronous PPP network. Driver 101 need not be aware that translation to 
Synchronous PPP is occurring before the data is actually transmitted on the 
45 network. According to one embodiment of the invention, the driver software 
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implements an Asynchronous PPP protocol as defined in RFC1662. Connection 
102 and converter 110 may be external to the physical housing of the PC, or 
converter 110 may be located within the PC housing, in which case connection 
102 will be within the PC. 

As described in more detail below, when DTE 100 is transmitting, 
converter 110 buffers the data received from DTE 100 and also converts the 
data from a Asynchronous PPP formatting to Synchronous PPP formatting. This 
conversion entails not only translating the signal transmission from 
asynchronous to synchronous, but also converting the higher layer data link 
protocol functions of Asynchronous PPP to Synchronous PPP. As the data is 
converted to a Synchronous PPP, converter 110 transmits the data to a 
digital carrier network capable of transmitting Synchronous data, such as 
ISDN Network 115. ISDN 115 is responsible for routing the data to the 
distant computing resource. The data is delivered by ISDN 115 to a 
Synchronous Router 120, which has connections 117 to the ISDN network and is 
capable of receiving Synchronous ppp data packets. Router 120 then 
translates received data for use on the central computer resource such as 
office LAN 125. 

Converter 110 similarly may receive data from ISDN 115 over 
20 connection 112. Data from ISDN 115 is transmitted from the central computer 
resource using a Synchronous PPP. Converter 110 receives Synchronous PPP 
data packets from network 115, buffers them, and translates the data to 
Asynchronous PPP. Converter 110 then sends that data to its attached DTE 
100 using Asynchronous PPP. 

25 Fi 9- 4 is a schematic block diagram of an 

Asynchronous/Synchronous Converter 110 according to one embodiment of the 
invention. Converter 110 contains OART Driver circuit 210, Asynchronous 
Packet Buffer 220, Asynchronous/Synchronous PPP Conversion Circuit 230, 
ACCM Memory 240, Synchronous Packet Buffer 250, and Synchronous Driver 

30 Circuit 260. UART driver circuit 210 receives characters from and transmits 
characters to UART 105 in DTE 100. As explained above, these characters are 
transmitted according to a standard asynchronous transmission protocol as 
defined by UART 105 and as programmed by the driver in DTE 100. The UART 
driver circuit strips off all start and stop bits of the received data and 

35 stores received characters in the Asynchronous Packet Buffer 220. After the 
characters are received by UART Driver Circuit 210, they are examined by 
Asynchronous /Synchronous PPP Conversion Circuit 230 to determine when a full 
packet has been received, when a full packet is received, Conversion Engine 
230 reads the Asynchronous PPP packet to determine if it is a LCP packet or 

40 a data packet. If the packet is a data packet. Engine 230 simply strips off 
the Asynchronous PPP formatting including any ESC characters and adds 
Synchronous PPP formatting and then stores the packet in Synchronous Packet 
Buffer 250. Once a full packet is present in Synchronous Packet Buffer 250, 
the packet is transmitted according to a Synchronous PPP on the ISDN line by 

45 Synchronous Driver Circuit 260. 
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For packets from the ISDN line to DTE 110, a reverse procedure 
is used. One addition to this procedure is that Engine 230 reads from ACCM 
buffer 240 a DTE-ACCM which specifies those characters that must be escaped 
according to the Asynchronous PPP requested by the DTE. If any characters 
5 need to be escaped, Engine 230 watches for those characters and inserts ESC 
characters into the data as needed before storing the packets in 
Asynchronous Packet Buffer 220* 

The operation of Converter 110 will be better understood by 
reference to Figs. 5, 6, and 7. Fig- 5 is a diagram illustrating the way in 
10 which a converter according to the invention handles LCP packets transmitted 
between the DTE and the network. The LCP is as specified in RFC1661 and 
RFC1662. The objective of the converter according to the invention is to 
specify as few control characters as possible in the respective ACCHs so as 
to reduce the number of ESC characters that need to be transmitted, but 
15 while doing that the converter must ensure that all characters that need to 
be escaped are properly escaped and must further ensure that LCP packets are 
properly acknowledged. RFC1661 and RFC1662 define an LCP protocol wherein 
either side of a PPP connection may transmit an LCP packet containing a 
configuration request (CR) . When either side of a PPP connection receives a 
20 LCP CR packet, it must respond with an LCP configuration acknowledge (CA) 

packet* A DTE device that wishes to have certain characters escaped sends a 
CR containing an ACCM to the other device on the PPP connection. The DTE 
dtvict then expects to receive a CA containing the same ACCM back from the 
other d«vice. If no ACCM is included in a CR packet, the default ACCM is 
25 assumed, which in Asynchronous PPP is to escape all control characters and 
in Synchronous PPP is to escape no control characters. 

Fig. 5 illustrates how a converter (or DCE) according to the 
invention handles LCP CR and CA packets. When DTE 100 sends a CR containing 
a DTE -ACCM (300), converter 110 stores the DTE -ACCM and then transmits the 
30 CR with no ACCM to Synchronous Router 120 over network 115 (302). When 
Synchronous Router 120 responds with a CA containing no ACCM (304), 
converter 110 intercepts the CA and restores to it the DTE— ACCM before 
transmitting it to DTE 100 (306). Similarly, when Router 120 sends a CR 
containing a net-ACCM (308), converter 110 stores the net-ACCM and then 
35 inserts its own DCE-ACCM into the CR packet and transmits the CR with a DCE- 
ACCM to DTE 100 (310). Note that the net-ACCM in all presently available 
synchronous devices will either be absent or, equivalently , set to 0, 
indicating that no bytes need to be escaped for the synchronous device. 
Whether or not the net-ACCM is present in the CR, converter 110 inserts its 
40 DCE-ACCM before transmitting the CR to the DTE. The DCE-ACCM will also 

ideally be 0, indicated that no characters need be escaped in transmissions 
from DTE 100 to DCE 110. However, when converter 110 is configured to 
perform XON/XOFF over its asynchronous connection, the DCE-ACCM will be 
O0OAO0OO hex, indicating that DTE 100 must escape the XON/XOFF control 
45 codes. When DTE 100 responds with a CA containing the DCE-ACCM (312), 
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15 



20 



converter 110 intercepts the CA and restores the net-ACCM or if there is no 
net-ACCM, deletes the DCE-ACCM before transmitting the CA to Router 120 
(314). 

Fig. 6 is a flow chart showing the process of conversion of 
5 Asynchronous PPP packets to Synchronous PPP packets* Asynchronous 

characters are received at converter 110 and stored in an Asynchronous 
Packet Buffer (Step S2 ) . When a Asynchronous PPP packet is fully received 
from the DTE, the Asynchronous PPP formatting is removed, with escape 
characters deleted- (Step S4). Then, converter 110 examines the Protocol 
10 Identification and Packet Code fields of the asynchronous packet to 

determine if the packet is an LCP parameter negotiation packet (Step S6). 
If the packet is not one of the LCP parameter negotiation packets, the 
packet is encapsulated in a synchronous PPP packet using bit-stuffing and 
has escape characters added as specified by the net-ACCM if present in 
memory 240 by converter 110 and then transmitted (Step S14) . The packet is 
transmitted over the ISDN digital network 115 where it may be received by 
Synchronous Router 120 and then routed on LAN 125 . 

If the packet is an LCP packet then it is examined further to 
see if it is a Configuration Request (Step S8). If the packet is a LCP CR 
specifying an ACCM, then the ACCM specified in this packet is stored in ACCM 
memory 240 as the DTE-ACCM (Step S10). If the packet is an LCP 
Configuration Request that does not contain an ACCM, the DTE is implicitly 
specifying to use the default Asynchronous PPP ACCM of escaping all control 
characters, and that information is stored in memory 240. In either case, 
if the LCP packet contains an ACCM, the Packet is modified by substituting 
the net-ACCM for the DTE-ACCM before being transmitted over the digital 
network (Step S12). Where there is no net-ACCM, the DTE-ACCM is simply 
removed from the packet. Removing the ACCM from the LCP packet implies to 
the Synchronous PPP router that the DTE requests the default Synchronous PPP 
30 ACCM (which means that no characters are escaped). 

Fig. 7 is a flow chart showing the process of conversion of 
Synchronous PPP packets to Asynchronous PPP packets. When a PPP packet is 
received from the digital network, the synchronous PPP formatting is 
removed. If the packet is not one of the LCP parameter negotiation packets 
(Step T6), the packet is encapsulated in an asynchronous PPP packet using 
the byte-stuffing procedure defined in RFC1662 and those control codes 
specified in DTE-ACCM are escaped and the packet and is transmitted to DTE 
100 over the asynchronous interface (Step T16). 

If the packet is an LCP packet, it is further examined to 
determine if it is a Configuration Request (Step T8). If it is a CR, then 
the DCE-ACCM is inserted into the packet, any net-ACCM is stored in memory 
240 and the packet is transmitted according to Step T16. If the packet is 
not a CR r it is further examined to determine if it is a Configuration 
Acknowledge (Step T12 ) . If the packet is a CA, then the DTE-ACCM is 
restored to the packet from memory 240 before the packet is transmitted 



25 



35 



40 



45 
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according to Step T16. 

If the packet is any other LCP parameter negotiation packet, the 
contents of the packet are examined. If the packet contains any ACCM, the 
packet is modified by removing the ACCM before it is transmitted to the DTE 
5 using the asynchronous PPP procedure described above. 

An Appendix totalling 18 pages is attached to this application. 
The appendix provides detailed circuit schematics for one embodiment of the 
invention. Applicants request that this Appendix be maintained in the file 
of the patent application but not be reproduced as part of the patent when 
10 issued. 

The invention has now been explained with reference to specific 
embodiments. Other embodiments will be apparent to those of skill in the 
art. In particular, method steps have been grouped and labelled as being 
part of various sub-methods in order to increase clarity of the disclosure, 

15 however, these steps could be differently grouped without changing the 
essential operation of the invention. Methods according to the present 
invention may be embodied as a compiled version of this source code stored 
on a floppy disk, hard disk, optical disk, or in a computer memory. Also, 
some of the methods described above as performed by hardware could be 

20 performed by software and vice versa. It is therefore not intended that 
this invention be limited, except as indicated by the appended claims. 
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WHAT IS CLAIMED IS ; 

1 1. A convertor for two-way communication between a first device 

2 ueing asynchronous communication (the asynchronous device) and a second 

3 device using synchronous communication (the synchronous device) comprising: 

4 an asynchronous driver capable of two way asynchronous 

5 communication with said asynchronous device; 

6 a synchronous driver capable of two way synchronous 

7 communication with said synchronous device; 

8 an asynchronous data buffer for storing units of asynchronous 

9 data received from said asynchronous device and for storing units of 
asynchronous data prior to transmission to said asynchronous device; 

11 a synchronous data buffer for storing units of synchronous data 

12 received from said synchronous device and for storing units of synchronous 

13 data prior to transmission to said synchronous device; 

14 an asynchronous/synchronous translator capable of translating 

15 between asynchronous and synchronous data formats, said converter capable of 

16 reading complete units of asynchronous data from said asynchronous data 

17 buffer, translating control fields and formatting to a form suitable for 

18 synchronous transmission, and storing complete units of synchronous data 

19 into said synchronous data buffer, said converter further capable of reading 

20 complete units of synchronous data from said synchronous data buffer, 

21 translating control fields and formatting to a form suitable for 

22 asynchronous transmission, and storing complete units of asynchronous data 

23 into said asynchronous data buffer; and 

24 a converter memory for storing protocol control values received 

25 from said first device or said second device, said memory connected to said 
2 6 converter - 

1 2. The converter according to claim 1 wherein said translator 

2 stores in said converter memory at least a character control map specifying 

3 which characters in a transmission from said converter must be escaped. 

1 3. The converter according to claim 2 wherein said translator 

2 is enabled to examine packets received from said asynchronous driver to 

3 determine if those packets are link control packets containing a received 

4 character control map and wherein said received character control map is 

5 stored in said converter memory. 

1 4. The converter according to claim 1 wherein said asynchronous 

2 data buffer, said synchronous data buffer, and said converter memory are 

3 delineated blocks of memory in a shared random access memory. 

1 5. The converter according to claim 1 as used in a data 

2 communication connection, wherein said connection further comprises: 

3 a data terminal equipment device having asynchronous driver 
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4 

5 



software and an asynchronous driver circuit operably connected to an 
asynchronous connector of said converter; 

a synchronous digital network operably connected to a 
r synchronous connector of said converter; 

1 a synchronous receiver operably connected said to a said 

> synchronous digital network for exchanging packets of data with said data 
) terminal equipment device over said digital network with translation by said 
L converter. 

! 6. An asynchronous/ synchronous converter for two-way 

2 communication between an asynchronously communicating DTE device and a 

3 synchronous digital network comprising: 

an asynchronous driver capable of two way asynchronous 

communication with a standard universal asynchronous receiver transmitter 

6 (UART) ; 

7 a synchronous driver capable of two way synchronous 

8 communication with a digital network; 

an asynchronous data buffer for storing asynchronous PPP data 

packets received from said DTE and for storing asynchronous PPP data packets 

11 prior to transmission to said asynchronous device; 

12 a synchronous data buffer for storing asynchronous PPP data 
packets received from said DTE prior to transmission to said network and for 
storing synchronous PPP data packets received from said network; 

A3 an asynchronous/synchronous translator capable translating 

16 between asynchronous PPP and synchronous PPP formats, said converter capable 

17 of reading complete asynchronous PPP packets from said asynchronous data 

18 buffer, translating control fields and formatting to a form suitable for 

19 synchronous PPP transmission, and storing complete synchronous PPP data 

20 packets into said synchronous data buffer, said converter further capable of 

21 reading complete synchronous PPP packets from said synchronous data buffer, 

22 translating control fields and formatting to a form suitable for 

23 asynchronous PPP transmission, and storing complete asynchronous PPP packets 

24 into said asynchronous data buffer; and 

25 a converter memory for storing Asynchronous Control Character 

26 Map (ACCM) protocol control values received from said first device or said 

27 second device, said memory connected to said converter and said converter 

28 reading data stored in said memory to facilitate in translation. 

7. The converter according to claim 6 wherein said translator 
stores in said converter memory at least a character control map specifying 
which characters in a transmission from said converter must be escaped. 



9 
10 



13 
14 
IS 



1 
2 
3 



! 8. The converter according to claim 7 wherein said translator 

2 is enabled to examine packets received from said asynchronous driver to 

determine if those packets are link control packets containing a received 
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4 character control map and wherein said received character control map is 

5 stored in said converter memory. 
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9. The converter according to claim 6 wherein said asynchronous 
data buffer, said synchronous data buffer, and said converter memory are 
delineated blocks of memory in a shared random access memory. 



1 10. The converter according to claim 6 as used in a data 

2 communication connection, wherein said connection further comprises: 

a data terminal equipment device having asynchronous driver 

software and an asynchronous driver circuit operably connected to an 

5 asynchronous connector of said converter; 

6 a synchronous digital network operably connected to a 

7 synchronous connector of said converter; 

8 a synchronous receiver operably connected said to a said 
synchronous digital network for exchanging packets of data with said data 
terminal equipment device over said digital network with translation by said 

11 converter. 



1 11. A method for converting link control packets between a DTE 

2 device using Asynchronous PPP and a network device using Synchronous PPP 

3 comprising the steps of: 

4 detecting each time said DTE sends a configuration request 

5 packet containing a DTE-Asynchronous Character Control Map (ACCM) , and when 

6 such a packet is received storing the DTE— ACCM, deleting the ACCM from the 

7 packet, and transmitting said DTE configuration request packet to said 

8 network device using a Synchronous PPP; 



detecting each time said network device sends a configuration 
acknowledge packet and when such a packet is received restoring said stored 
DTE— ACCM to the packet and transmitting said network configuration 
acknowledge packet to said DTE using an Asynchronous PPP; 

detecting each time said network device sends a configuration 
request packet, and if the packet contains a net-ACCM storing the net -ACCM 
and removing the net-ACCM from the packet, then inserting a DCE-ACCM into 
the network configuration request packet and transmitting said configuration 
request packet to said DTE using an Asynchronous PPP; and 

detecting each time said DTE sends a configuration acknowledge 
packet and when such a packet is received deleting said DCE-ACCM from the 
packet and restoring said stored net-ACCM to the packet and transmitting 
said DTE configuration acknowledge packet to said network device using a 



22 Synchronous PPP. 



12. The method according to claim 11 further comprising the 
2 step of: 



3 



using said stored DTE -ACCM to determine which characters must be 
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4 preceded by an escape character before transmission to said DTE using an 

5 Asynchronous PPP. 

1 13. The method according to claim 11 further comprising the 

2 step of: 

3 using said stored net-ACCM to determine which characters must 

4 preceded by an escape character before transmission to said network devic 

5 using a Synchronous PPP. 
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CR = Configure Request 
CA = Configure Acknowledge 
dte-ACCM = ACCM from the DTE 
dce-ACCM = OxOOOAOOOO (XON, XOFF) 
net-ACCM = ACCM from the digital network 
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